f********a
发帖数: 165 | 1 Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
根据你的设计而提出后续问题。）
特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
。 |
g**u
发帖数: 504 | 2 帮顶，求大牛解惑
【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
|
s**********r
发帖数: 8153 | |
h*****a
发帖数: 1718 | 4 随便抛块砖。
如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
要考虑的有以下几点：
1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
uid+updateId)。这些都是我的假设，需要对方confirm。
如果对方认可，那每天需要传送到活跃用户wall上的数据是50Byte * 100M * 50 =
250G bytes ， 约为 3MB/second。考虑到要能处理spike，可以设计传输的capacity为
10MB/second.
存储系统只需存储过去两周的数据，50M * 10 * 50byte = 25GB，考虑peak, 50G，数
据量很小。历史数据暂不考虑。
2）确定采用push 还是pull来发送更新。一般来说用push，但需要比较两种选择各自的
优劣。pull需要对服务器做很多无效的轮询，push相对效率高一些。但要考虑对不活跃
用户和未登录用户不需实时发送（可以backgroud非实时发送），来优化系统。
3）如何发送，一般来说一个更新submit之后，会放到一个Message Queue中，再由一个
publish service (cluster)来一条一条处理。publisher拿到一条message后，根据发
布人的friend list计算出需要deliver到哪些user，然后定位负责deliver到这些user
的服务器，把更新交给他们处理。这里就涉及到暂时过滤掉没有在线的不活跃用户，以
降低需要deliver的数目。所以应该还要设计一个offline的deliver queue, 可以在系
统不繁忙的时候做非实时的delivery。
delivery采用分布式设计，分级结构（比如邮局），可以通过consistent hash迅速定
位到server来处理发送到某个user的message。这里有很多细节可以讨论，比如如何实
现consistent hash，如何group users by their location and select the closest
server to deliver the update, etc.
4）客户端显示更新。每个用户有一个update message queue，存放应该显示给他的
updates。这里可以讨论如何排序这些更新，可以比如根据friend graph先显示重要
friend的更新，也有很多可以讨论的东西。
估算系统需要的服务器数量：
1） Persistent DB storage，数据量25GB－50G，都可以放到内存中。所以一个3个
server的MySQL cluster就够了。一般来说，每个region会有一个自己的cluster，所以
要根据region的数目来估算，比如如果有10个region，就是30台server。
2）publish service也是要分布在不同的region上。假定每个cluster平均负责200M
user，可能需要5台server来处理全部用户，如果10个region，那就是50台server。当
然，这种估算都是很不精确的。要根据具体的情况调整。一般来说都是弹性设计系统，
根据traffic和系统负载随时调整server数量，这里说的只是一个rough的对最大size的
估计。
【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
|
J****3
发帖数: 427 | |
c******a
发帖数: 789 | 6 赞半海。
fb最近开发好一个叫虫洞的system，就是您提到的message system，顺便提一下可以拉
拉关系。 |
c******a
发帖数: 789 | 7 所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
就不用管了。 |
h*****a
发帖数: 1718 | 8 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
好。
【在 c******a 的大作中提到】
: 所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
: delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
: 就不用管了。
|
|
c******a
发帖数: 789 | 9 确实是！！
醍醐灌顶，谢谢大牛！
【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
|
w******j
发帖数: 185 | |
|
|
z****e
发帖数: 54598 | 11 这种数据没有必要上db了，nosql就好了
cassandra
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
h*****a
发帖数: 1718 | 12 noSql在我看来也是DB了。反正就是个用来做persitence的东东，因为运行时数据都在
内存里了。
【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
|
h*****a
发帖数: 1718 | |
w**z
发帖数: 8232 | 14 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。
【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
|
g**e
发帖数: 6127 | 15 FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
|
z****e
发帖数: 54598 | 16 如果不用transaction同时不用各种join的话
应该会好点
不过有些框架默认要上transaction，这个很头疼
光是去关掉这个设置就要折腾半天
hibernate就是典型
【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
|
p*****2
发帖数: 21240 | 17
timestamp+
push的话一般有什么机制？web socket吗？
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
g**u
发帖数: 504 | 18 你们是哪家，twitter也用Cassandra实现的吧？ Facebook 好像用的pull, 存储和查询
用的是一个类似 leveldb的东西，不知道现在还是不是这样的。
用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。
【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
|
h*****a
发帖数: 1718 | 19 Not sure, maybe something like http://en.wikipedia.org/wiki/Comet_(programming)
【在 p*****2 的大作中提到】
:
: timestamp+
: push的话一般有什么机制？web socket吗？
|
w******j
发帖数: 185 | 20
那么现在用什么做了？请教啊....
【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
|
|
|
z****e
发帖数: 54598 | 21 cassandra就是facebook自制的nosql，后来贡献给apache了
如果不是cassandra的话，我觉得前面某人说的换hbase的可能性更大
【在 w******j 的大作中提到】
:
: 那么现在用什么做了？请教啊....
|
s*****r
发帖数: 43070 | 22 post to web service
【在 p*****2 的大作中提到】
:
: timestamp+
: push的话一般有什么机制？web socket吗？
|
l*****t
发帖数: 2019 | 23 now hbase. Cassandra was out. this is old news.
【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
|
w******j
发帖数: 185 | 24 我听说的是，facebook从来也没用cassandra做news feed啊，以前只是用它做inbox
search，现在用hbase来做了，和news feed没关系啊..... |
f********a
发帖数: 165 | 25 大牛啊。多谢！
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
f********a
发帖数: 165 | 26 半海，能否讲讲设计photo sharing和news feed的区别？
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
Y********f
发帖数: 410 | 27 没有登录的用户为啥还要update，难道不是用户登录的时候在临时生成页面吗？
【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
|
x*****0
发帖数: 452 | |
v***n
发帖数: 562 | 29 mark
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
b*******n
发帖数: 847 | |
|
|
B*****g
发帖数: 34098 | 31 换的原因是。。。？
【在 l*****t 的大作中提到】
: now hbase. Cassandra was out. this is old news.
|
u*****o
发帖数: 1224 | |
h****p
发帖数: 87 | |
s*****d
发帖数: 66 | |
x*****0
发帖数: 452 | |
f********a
发帖数: 165 | 36 Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
根据你的设计而提出后续问题。）
特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
。 |
g**u
发帖数: 504 | 37 帮顶，求大牛解惑
【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
|
s**********r
发帖数: 8153 | |
h*****a
发帖数: 1718 | 39 随便抛块砖。
如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
要考虑的有以下几点：
1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
uid+updateId)。这些都是我的假设，需要对方confirm。
如果对方认可，那每天需要传送到活跃用户wall上的数据是50Byte * 100M * 50 =
250G bytes ， 约为 3MB/second。考虑到要能处理spike，可以设计传输的capacity为
10MB/second.
存储系统只需存储过去两周的数据，50M * 10 * 50byte = 25GB，考虑peak, 50G，数
据量很小。历史数据暂不考虑。
2）确定采用push 还是pull来发送更新。一般来说用push，但需要比较两种选择各自的
优劣。pull需要对服务器做很多无效的轮询，push相对效率高一些。但要考虑对不活跃
用户和未登录用户不需实时发送（可以backgroud非实时发送），来优化系统。
3）如何发送，一般来说一个更新submit之后，会放到一个Message Queue中，再由一个
publish service (cluster)来一条一条处理。publisher拿到一条message后，根据发
布人的friend list计算出需要deliver到哪些user，然后定位负责deliver到这些user
的服务器，把更新交给他们处理。这里就涉及到暂时过滤掉没有在线的不活跃用户，以
降低需要deliver的数目。所以应该还要设计一个offline的deliver queue, 可以在系
统不繁忙的时候做非实时的delivery。
delivery采用分布式设计，分级结构（比如邮局），可以通过consistent hash迅速定
位到server来处理发送到某个user的message。这里有很多细节可以讨论，比如如何实
现consistent hash，如何group users by their location and select the closest
server to deliver the update, etc.
4）客户端显示更新。每个用户有一个update message queue，存放应该显示给他的
updates。这里可以讨论如何排序这些更新，可以比如根据friend graph先显示重要
friend的更新，也有很多可以讨论的东西。
估算系统需要的服务器数量：
1） Persistent DB storage，数据量25GB－50G，都可以放到内存中。所以一个3个
server的MySQL cluster就够了。一般来说，每个region会有一个自己的cluster，所以
要根据region的数目来估算，比如如果有10个region，就是30台server。
2）publish service也是要分布在不同的region上。假定每个cluster平均负责200M
user，可能需要5台server来处理全部用户，如果10个region，那就是50台server。当
然，这种估算都是很不精确的。要根据具体的情况调整。一般来说都是弹性设计系统，
根据traffic和系统负载随时调整server数量，这里说的只是一个rough的对最大size的
估计。
【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
|
J****3
发帖数: 427 | |
|
|
c******a
发帖数: 789 | 41 赞半海。
fb最近开发好一个叫虫洞的system，就是您提到的message system，顺便提一下可以拉
拉关系。 |
c******a
发帖数: 789 | 42 所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
就不用管了。 |
h*****a
发帖数: 1718 | 43 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
好。
【在 c******a 的大作中提到】
: 所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
: delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
: 就不用管了。
|
c******a
发帖数: 789 | 44 确实是！！
醍醐灌顶，谢谢大牛！
【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
|
w******j
发帖数: 185 | |
z****e
发帖数: 54598 | 46 这种数据没有必要上db了，nosql就好了
cassandra
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
h*****a
发帖数: 1718 | 47 noSql在我看来也是DB了。反正就是个用来做persitence的东东，因为运行时数据都在
内存里了。
【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
|
h*****a
发帖数: 1718 | |
w**z
发帖数: 8232 | 49 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。
【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
|
g**e
发帖数: 6127 | 50 FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
|
|
|
z****e
发帖数: 54598 | 51 如果不用transaction同时不用各种join的话
应该会好点
不过有些框架默认要上transaction，这个很头疼
光是去关掉这个设置就要折腾半天
hibernate就是典型
【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
|
p*****2
发帖数: 21240 | 52
timestamp+
push的话一般有什么机制？web socket吗？
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
g**u
发帖数: 504 | 53 你们是哪家，twitter也用Cassandra实现的吧？ Facebook 好像用的pull, 存储和查询
用的是一个类似 leveldb的东西，不知道现在还是不是这样的。
用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。
【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
|
h*****a
发帖数: 1718 | 54 Not sure, maybe something like http://en.wikipedia.org/wiki/Comet_(programming)
【在 p*****2 的大作中提到】
:
: timestamp+
: push的话一般有什么机制？web socket吗？
|
w******j
发帖数: 185 | 55
那么现在用什么做了？请教啊....
【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
|
z****e
发帖数: 54598 | 56 cassandra就是facebook自制的nosql，后来贡献给apache了
如果不是cassandra的话，我觉得前面某人说的换hbase的可能性更大
【在 w******j 的大作中提到】
:
: 那么现在用什么做了？请教啊....
|
s*****r
发帖数: 43070 | 57 post to web service
【在 p*****2 的大作中提到】
:
: timestamp+
: push的话一般有什么机制？web socket吗？
|
l*****t
发帖数: 2019 | 58 now hbase. Cassandra was out. this is old news.
【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
|
w******j
发帖数: 185 | 59 我听说的是，facebook从来也没用cassandra做news feed啊，以前只是用它做inbox
search，现在用hbase来做了，和news feed没关系啊..... |
f********a
发帖数: 165 | 60 大牛啊。多谢！
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
|
|
f********a
发帖数: 165 | 61 半海，能否讲讲设计photo sharing和news feed的区别？
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
Y********f
发帖数: 410 | 62 没有登录的用户为啥还要update，难道不是用户登录的时候在临时生成页面吗？
【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
|
x*****0
发帖数: 452 | |
v***n
发帖数: 562 | 64 mark
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
b*******n
发帖数: 847 | |
B*****g
发帖数: 34098 | 66 换的原因是。。。？
【在 l*****t 的大作中提到】
: now hbase. Cassandra was out. this is old news.
|
u*****o
发帖数: 1224 | |
h****p
发帖数: 87 | |
s*****d
发帖数: 66 | |
x*****0
发帖数: 452 | |
|
|
c*********n
发帖数: 1057 | 71 大牛好像重点讲了怎么设计news feed，但是还是不知道应该怎么样计算需要几个
server,大牛assume一个server可以handle 200M user，面试点时候可以这么assume吗？
我主要是stuck在，计算好了需要多少disk space and thoughput以后，怎么样map 到
多少server呢？
请大牛指点 |
h*****a
发帖数: 1718 | 72 你对单机的计算能力要有估算啊。还要考虑比如你的应用是CPU boun d还是memory
bound。原题本身就是很简化的估算一下，现实中肯定要复杂一些。
一般来说， launch之前要做load testing，来confirm你的估算基本上make sense。
作为launch的一部分，要对service cluster，database，甚至上游下游的service set
up metrics来监控load的情况（e.g. CPU, memory, network, etc.)。
service的 设计中一定要考虑到scalability，如果发现初始计划的cluster size无法
handle peak的traffic,就要考虑增加机器的数目。Well designed的service应该是可
以方便的通过增加机器来scale的。Initial的size不能适应实际load的情况是很常见的。
现实中经常会用到auto-scaling，就是在peak和non-peak的时间用不同数目的机器。
吗？
【在 c*********n 的大作中提到】
: 大牛好像重点讲了怎么设计news feed，但是还是不知道应该怎么样计算需要几个
: server,大牛assume一个server可以handle 200M user，面试点时候可以这么assume吗？
: 我主要是stuck在，计算好了需要多少disk space and thoughput以后，怎么样map 到
: 多少server呢？
: 请大牛指点
|
z***e
发帖数: 209 | |
s*****m
发帖数: 8094 | 74 inceemental updates (publish) + full/on demand sync (pull)
【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
|
s*****m
发帖数: 8094 | 75 scalable么？
【在 Y********f 的大作中提到】
: 没有登录的用户为啥还要update，难道不是用户登录的时候在临时生成页面吗？
|
s*****m
发帖数: 8094 | 76 for 3, be careful with scheduling and resource usage for users with large
amount of connections.
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
i**d
发帖数: 357 | 77 F应该不太可能用HBASE来serve newsfeed这么heavy的read load吧。
听说他们现在用的多的是这个:
http://www.quora.com/Facebook-Infrastructure/What-is-the-TAO-ca |
r****c
发帖数: 2585 | 78 这个没有底的，facebook自己也在不停improve
for example，一个信息发布以后当这个信息like量变大的时候，他的score 会变大，
所以不光是news published的时候，而是news score change也会影响。总的来说一般
要scalable都是incremental update，通过event base 来 push到 pub，然后sub方
filter out
timestamp+
【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
|
c******3
发帖数: 296 | 79 感觉大牛这点没讲透。能否具体说说一台机器何以处理多少请求？1000人次还是1百万
人次？另外Facebook是用什么作webserver呢？Tomcat?不同的webserver，能力也不一
样。
详细讨论用什么样的机器合适，很有的讨论，但能不能通过面试，可能要看面试官是魏
老师还是goodbug了。站错队，很危险
set
的。
【在 h*****a 的大作中提到】
: 你对单机的计算能力要有估算啊。还要考虑比如你的应用是CPU boun d还是memory
: bound。原题本身就是很简化的估算一下，现实中肯定要复杂一些。
: 一般来说， launch之前要做load testing，来confirm你的估算基本上make sense。
: 作为launch的一部分，要对service cluster，database，甚至上游下游的service set
: up metrics来监控load的情况（e.g. CPU, memory, network, etc.)。
: service的 设计中一定要考虑到scalability，如果发现初始计划的cluster size无法
: handle peak的traffic,就要考虑增加机器的数目。Well designed的service应该是可
: 以方便的通过增加机器来scale的。Initial的size不能适应实际load的情况是很常见的。
: 现实中经常会用到auto-scaling，就是在peak和non-peak的时间用不同数目的机器。
:
|
